The present invention relates generally to systems implementing mobile content and metadata management. More particularly, this invention relates to the deployment and management of location-based technologies in the context of mobile content management systems. Exemplary embodiments of location-based technologies as described herein include a managed network of Bluetooth Low Energy (“BLE”) beacons, near field communication (NFC) tags, QR codes and the like.
There are several protocols in the market over which such content source devices operate, including for example Apple's iBeacon protocol in the case of BLE beacons. The iBeacon protocol consists of a fixed length bit package (UUID/Major Identifier/Minor Identifier) that is in turn interpreted by compatible mobile Apps. However, in order to truly unlock the potential for interaction with any “smart device” upon demand, it would be desirable to reduce or eliminate the need for users to download an app associated with each respective group of devices. In keeping with the objective of rapid expansion of the Web into the physical world, it is therefore desirable to make the process of adding an element just as simple as adding a new web page.
Alternative and open source protocols such as UriBeacon and Eddystone-URL have been implemented, and may be referred to herein as Physical Web beacons, wherein the beacons broadcast a Uniform Resource Identifier (“URI”) such as without limitation a Uniform Resource Locator (“URL”) or uniform Resource Name (“URN”), in the context of accessing a network location such as a website address. As used herein, URI may refer interchangeably to a unique identifier associated with a beacon, a URN, or a URL, except in instances where the URL is specified as including the unique identifier associated with the beacon (the URI). The Physical Web (PW) has been promoted as a primary link between the physical world and the Internet, where places and things in can communicate via websites. Much like QR codes, PW beacons will be universally accessible to compatible apps and browsers, and will not require a custom App, as are required by, e.g., the iBeacon protocol.
The conventional mode of operation with a PW beacon is straightforward. One benefit of beacons that broadcast URLs rather than unique IDs is that any compatible application, collectively referred to herein as PW browsers, can retrieve the website associated with the URL broadcast by PW beacons. The most common use of a PW browser is that the user initiates a scan for nearby content, which displays a visual list of the metadata associated with nearby websites, whereupon the user selects one of interest and is directed to that website (URL). The experience is much like that from the common internet browser, which displays a snapshot of available websites based upon search terms, except that the user does not enter search term, but instead, the list of available websites is based upon proximity to the user.
With an administrative App designed to configure beacons, and when physically near to the target beacon, one can connect with a PW beacon and program it with the URI in combination with a network location and methodology of retrieving content from said destination—in practical terms a URL. The target beacon references this URI to broadcast the desired URL. A special browser executable from a client device is configured to read the broadcast from that beacon and connect to the destination URL in the normal way.
However, in order to connect to current Bluetooth beacons such as a UriBeacon or Eddystone beacon and change the URL which it advertises, the user must be physically near the beacon, because the process is accomplished over a Bluetooth low energy link, which has a limited range. This proximity requirement can be particularly problematic where the user wishes to implement and provide periodic updates for numerous beacons across an inconveniently large area, or otherwise make appropriate range settings for a suitable user experience. The associated need for an unfamiliar, and sometimes awkward, programming task (e.g., taking the beacon's batteries out, or pushing a button) inhibits an otherwise familiar and straightforward process. This task is made unmanageable for widely dispersed installations by the requirement to have to handle each beacon in order to adjust its settings. Therefore, it would be desirable to eliminate the requirement of locally and directly interacting with the beacon for configuration by enabling a network-based management platform for the plurality of beacons in a dispersed installation.
Further, another limitation of the Eddystone and UriBeacon protocol is that the maximum size of the advertisement data field is 17 or 18 characters respectively (at present), so for example:                www.xxxxYYYY.comfits fine, as opposed to:        
https://github.com/google/uribeacon/tree/master/specification
For this reason, domain name shortening services are recommended and are commonly used with Eddystone beacons and UriBeacons. In the above example, if the second URL were plugged into the “Goo.gl” domain shortening application, the user would obtain http://goo.gl/Du29uS. If the user clicks on this link, he/she will be directed to the original link, but first must go to http://Goo.gl, where the link will be translated before redirection to the correct site. This one-to-one short-URL to destination-URL relationship can be problematic because the beacon is only allowed to broadcast a single shortened URL in reference to a third-party domain shortening service. For example, no additional URL information can be appended to the shortened URL, such as battery state or other sensor information tags so as to be passed through the URL to the destination location for contextual determination purposes. It would therefore be desirable to eliminate not only the step of interacting directly with the beacon, but further or at least in the alternative the need for third-party domain shortening applications for destinations having more than 18 characters, and to provide a methodology where contextual information appended to or embedded in a shortened URL by the beacon can be transferred to the associated destination URL.
Another problem in conventional applications is that websites currently have embedded content that is displayed by a browser upon search, commonly referred to as metadata. These typically include the website's title, its favicon, its description, etc. Because this information is embedded in the website, it is not easily changed without making direct changes to the website. For websites displayed on a beacon browser (e.g., PW browser) it would be beneficial if the website's metadata could be dynamically changed.
For example, if a restaurant's menu is on a website to be accessed and reviewed by people near to the restaurant, then it would be desirable to the restaurant owner to be able to change the title for that website (as displayed on a person's browser) to say “Meat Loaf Special today” or “2 for 1 PBR's” or “Free appetizer's for the next hour” or whatever message the restaurant wants to broadcast in order to capture the attention of passing consumers when they scan for location-based websites, and it is preferred that this can be done without having to change the underlying website.
Still another problem with conventional techniques is that beacons currently broadcast content through simple strings including URLs. As such, they are a powerful platform to make relevant content available to consumers in physical locations. However, if multiple beacons broadcast the same URL, then the source location of the user who accesses the beacons is lost. One reason for this is that many beacon browsers will retrieve the destination URL when the beacon is initially scanned, whereas that destination URL contains no reference to, or way of identifying, the originating location. Even if there is a code in the shortened URL, often all beacons use the same shortened URL to access the same destination URL, and because most PW browsers do not make a second call to a server when that URL is actually selected by the user, they cannot relate the shortened URL and the common destination URL when the destination is selected. It would therefore be desirable that when location based content is accessed, and when more than one location is associated with that content, that the point of origin of each access can be accurately identified.
Yet another problem with conventional Bluetooth beacon protocols such as iBeacon is that traditional beacons broadcast a static, unique ID associated with the broadcasting beacon. This static identifier creates security and privacy risks, as unauthorized individuals can easily obtain the beacon ID and “hijack” or “spoof” the beacon. This allows unauthorized users to duplicate the ID to fool other users or to track the location of a moving beacon by monitoring the proximity to the static beacon ID. It is therefore desirable to eliminate the need to for a static beacon ID in the beacon protocol, thereby improving network security and user privacy.
Turning to alternative implementations of content source devices, QR codes and NFC tags may also be attached to specific products located immediately next to other tagged products, such that consumers can choose a specific content or action of interest. However, QR code implementation in particular has some disadvantages with respect to user experience. For example, QR code implementation is a single step transaction that instantly takes a user to a destination, without a complete understanding of the associated content. The destination URL itself may be made available by certain conventional QR readers, but even then may provide no more than a shortened URL. A user may therefore be sent to a QR destination that is not secure, and/or includes content that is undesirable or inappropriate for the user. QR codes are also typically not location-aware, and multiple locations cannot be easily managed as a group while also maintaining discrete location awareness.
Another problem with conventional QR implementation is that they lack anti-spoofing or presence detection features.
Yet another problem with conventional QR implementation is that QR codes do not provide conditional content, enabling different content to be presented to users with different client applications or in view of other varying criteria. Generally speaking, QR codes do not allow content to be personalized, or to be restricted to authorized users, or to display different content to different audiences.
Yet another problem with conventional QR implementations is that QR codes are slow to render useful information to a user due to the necessity to visit the destination URL and download all the content from that website.
Yet another problem with conventional QR implementations is that the available metrics are minimally useful for determining the value to users of the underlying content. Typically, only a single “scan” metric is collected indicating the QR code was scanned; however, because users often have no preview information for the destination URL, a high number of scans may only mean that the QR code is in a visible location, rather than that its content is valued.
Yet another problem with conventional QR implementations is that they do not have the ability to offer a user multiple destination URL options prior to visiting a destination URL.